This invention is related to the field of system security. It is more particularly related to integration of the language run-time systems and operating systems.
Traditionally, the programming language field has concentrated on designing efficient run-time systems. The operating system field on the other hand has traditionally dealt with issues like security, fault isolation, and resource control. With the advent of new programming languages, like Java(trademark), (Java is a trademark of SUN MICROSYSTEMS INC.) attempts have been made to add security to the programming language. These attempts are viewed as inherently insecure by most experts in the field.
It is advantageous to have a virtual machine that integrates operating system style security, fault isolation, and resource control with semantic information provided by the programming language system. This enables provision of a much finer grained protection than is possible in an operating system, hardware fault isolation between these protection units, and fine grained resource control. None of these are presently available at an operating system or language level.
Introduction
Consider Java as an example. Java is a general-purpose programming language that has gained popularity as the programming language of choice for mobile computing. It is a language used for World Wide Web Programming, smart card programming, embedded device programming, and even for providing executable content for active networks. The three main reasons for this popularity are Java""s portability, its security properties, and its lack of explicit memory allocation. It is thus chosen as an example to show the deficiencies of current technology, and is herein used to describe the present invention to overcome these deficiencies.
A Java program consist of classes and objects which are compiled into machine-independent byte codes. These byte codes are executed by a Java Virtual Machine (JVM). This abstract machine provides a uniform execution environment over different architectures and operating systems. Besides portability, the Java Virtual Machine and a standardized set of Java packages also provide a number of security mechanisms to enforce protection among Java code. These built-in security mechanisms protect the JVM and benign programs from possible malevolent programs and restricts access to the system resources.
The Java security functionality is implemented in three layers. At the lowest level the byte code verifier verifies the validity of a Java class by performing control and data flow analysis on its byte codes. This establishes that the class confines its control transfers to valid locations inside that class and prevents the construction of references to data elements outside its scope.
The second security level is implemented by the Java security manager. This is a reference Monitor that has to be invoked explicitly, at the object""s discretion, by each method to control access to the object""s instance state.
The third protection level consists of signed Java code. Remote code is confined to a sandbox which prevents it from accessing System resources unless it was signed with the digital signature from an authority trusted by the JVM. In that case the code has full access to the system.
With the introduction of JDK 2 this security model has been enhanced to Support multiple security policies. A security Policy defines a set of permissions to system resources which are available to the code. Which policy is used depends on the digital signature attached to the code. Unlike the previous versions of the JDK, all code is signed. The permission sets define domains of Java classes which are granted the same rights.
The Java security model depends solely on the correctness of the Java Virtual Machine to isolate Java code. This is a problem in that a number of serious security flaws have been reported in various JVM implementations. More fundamental is the dependence on the correctness of a large program (for example, JDK 2 contains xcx9c1.6M lines of code) when software engineering research indicates that every 1000 lines of code may contain 35-80 bugs. Even very thoroughly tested programs still may contain about 0.5-3 bugs per 1000 lines of code.
Hardware virtual machines (i.e., CPU and MMU) on the other hand generally have a much better track record. Security sensitive hardware components like the MMU are much better understood and their isolation and interaction with the rest system are much better defined than for complex software systems. Hence hardware based solutions provide better security.
A second problem with Java""s security model is the discretionary security policy which is enforced by the security manager. For executing mobile code on the JVM and having it access System resources a mandatory security policy is better suited. That is, the security policy should be enforced outside of the executing Java program and could potentially be different for each Java class.
In order to overcome these problems the present invention provides a secure JVM which uses hardware protection domains to transparently and securely protect Java applets. The JVM tightly integrates operating system protection methods with the extra semantic information provided by the language run time system. It consists of a Java Nucleus process that loads Java classes into separate hardware protection domains and mediates access between them in much the same way processes are kept isolated by an operating system. In addition, the secure JVM solves a number of hard Java problems, such as providing resource access and resource usage control. All these security measures are, in the absence of security violations, transparent to the Java code.
The Java Nucleus uses an efficient inter-process communication mechanism for cross domain method invocations and uses shared memory to share data among different protection domains. The data is shared on demand using virtual memory remapping. In order to prevent false sharing or fragmentation data is relocated at run time. Data is shared as a result of a reference being passed as a cross protection domain method invocation (XMI) or the sharing of an object instance state. The garbage collector, which is a part of the Java Nucleus, handles multiple protection domains, run time data relocation, shared memory and the revocation of shared memory.
The present invention does not rely on software fault isolation techniques to enforce protection. Systems that do provide hardware protection are generally based on multiple independent JVM""s connected through an optimized remote method invocation (RMI) or shared memory implementation. RMI requires source annotations and uses a stub compiler for generating marshaling routines. None of these systems are fully transparent to the Java programs.
Thus an aspect of the present invention is to provide a virtual machine that integrates operating system style security, fault isolation, and resource control with semantic information provided by the programming language system. This enables among other things:
1) provision of a much finer grained protection than is possible in an operating system,
2) hardware fault isolation between these protection units, and
3) fine grained resource control. Neither of these were previously possible at operating system or language level.